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1  Introduction 

“Active  networks  explore  the  idea  of  allowing  routing  elements  to  be  extensively  programmed 
by  the  paekets  passing  through  them.  This  allows  eomputation  previously  possible  only  at  end 
points  to  be  earried  out  within  the  network  itself,  thus  enabling  optimizations  and  extensions  of 
current  protoeols  as  well  as  the  development  of  fundamentally  new  protoeols.”  (Taken  from  the 
Switehware  Home  Page  [16]).  Our  thesis  is  that  sinee  networks  form  part  of  the  eritieal 
infrastrueture  of  distributed  systems,  the  added  eapability  to  dynamieally  program  and  modify 
the  behavior  of  active  networks  means  that  the  applieation  of  formal  modeling  and  analysis 
teehniques  to  the  design  and  development  of  new  protocols  and  active  paeket  programs  ean  be 
very  helpful.  To  test  this  thesis  we  have  earried  out  a  number  of  ease  studies  using  the  rewriting 
logie  language  Maude  and  assoeiated  tools  [2]. 

The  formal  methodology  underlying  our  approaeh  ean  be  summarized  by  stating  that  a  small 
amount  of  formal  methods  can  go  a  long  way.  Approaehes  requiring  full  mathematieal 
verifieation  of  a  system  can  be  too  eostly.  Proof  efforts  should  be  used  judieiously  and 
seleetively,  earefully  ehoosing  those  properties  for  whieh  a  very  high  level  of  assuranee  is 
needed.  However,  there  are  many  important  benefits  that  ean  be  gained  from  “lighter”  uses  of 
formal  methods,  without  neeessarily  requiring  a  full-blown  proof  effort.  A  simple  exeeutable 
specification  can  already  be  useful  for  rapid  prototyping  to  find  bugs  and  ineonsisteneies  in  the 
design,  and  as  a  preeise  doeumentation  of  a  system’s  design,  that  ean  also  be  used  as  a  elear 
means  of  eommunieation  between  development  teams.  Unfortunately,  executability  is  aetually 
not  enough.  Sinee  a  eoneurrent  system  ean  have  many  different  behaviors,  to  properly  analyze 
the  system  it  beeomes  important  to  explore  not  just  the  single  execution  provided  by  some 
default  strategy,  but  many  other  exeeutions.  Under  assumptions  of  finite-state  or  of  termination  it 
may  even  be  possible  to  analyze  all  exeeutions.  Finally,  one  ean  move  to  a  two-level 
speeifieation  augmenting  system-level  exeeutable  specifieations  with  specifications  of  high-level 
properties  expressed  in  nonexeeutable  formalisms  such  as  first-order,  higher-order,  temporal  or 
modal  logies  to  analyze  and  verify  these  more  eomplex  properties. 

Maude  supports  this  approach  very  well.  The  Maude  interpreter  is  very  effieient,  allowing 
prototyping  of  quite  eomplex  test  eases.  It  also  provides  a  number  of  debugging  aids  sueh  as 
traeing  (seleeted)  exeeution  steps.  The  refieetive  eapabilities  of  rewriting  logie  and  Maude  [4] 
low  user-  defined  exeeution  strategies  to  be  formally  speeified  by  rewrite  rules  at  the  meta-level. 
This  allows  easy  exploration  of  state  spaees  of  interest,  including  strategies  such  as  breadth-first 
seareh  that  ean  exhaustively  explore  all  the  executions,  up  to  some  depth,  of  a  system  from  a 
given  initial  state.  Maude  now  provides  efficient  built-in  seareh  and  model  eheeking  eapabilities. 
The  seareh  faeility  ean  be  used  to  find  states  matehing  some  pattern  reaehable  from  a  given 
initial  state.  The  model  eheeker  can  be  used  to  test  an  initial  state  for  satisfaetion  of  formulae  in 
linear  temporal  logie.  A  eounterexample  is  returned  if  the  eheeker  finds  that  the  formula  is  not 
satisfied.  Several  additional  formal  tools  that  have  been  built  in  Maude  using  the  refieetive 
eapability  are  available.  These  inelude  a  theorem  proving  tool,  a  Chureh-Rosser  eheeker  tool 
with  several  extensions,  and  a  real-time  analysis  tool.  The  induetive  theorem  prover  for 
equational  logie  speeifieations  [3]  ean  be  used  to  prove  induetive  properties  of  functional 
modules  in  Maude.  The  Chureh-Rosser  eheeker  tool  [3]  analyzes  equational  speeifioations  to 
cheek  whether  they  satisfy  the  Chureh-Rosser  property.  The  tool  outputs  a  eolleetion  of  proof 
obligations  that  ean  either  be  proved  or  used  to  modify  the  speeifieation.  Extensions  of  this  tool 
to  perform  equational  eompletion  and  to  eheek  termination  and  eoherenee  of  rewrite  theories 
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have  also  been  developed  [12,  11],  An  exeeution  and  analysis  environment  for  speeifioations  of 
real-time  and  hybrid  systems  ealled  Real-Time  Maude  [40]  has  been  developed  based  on  a 
notion  of  real-time  rewrite  theory  that  has  a  straightforward  translation  into  an  ordinary  rewrite 
theory  [41],  This  tool  translates  real-time  rewrite  theories  into  Maude  modules  and  ean  execute, 
analyze,  and  model  check  such  theories  by  means  of  a  library  of  strategies  that  can  be  easily 
extended  by  the  user  to  perform  other  kinds  of  formal  analysis. 

Maude  executables,  its  manual,  most  of  the  above  tools,  and  a  collection  of  examples  and  papers 
are  available  on  the  Web  (http  :  / /maude  .  csl .  sri  .  com)  . 

In  summary,  using  Maude  to  formally  specify  and  analyze  communication  systems  offers  the 
following  advantages: 

•  Early  insertion  of  the  formal  method.  In  this  way,  maximum  benefit  can  be  obtained, 
since  the  design  can  be  corrected  very  early,  before  heavy  implementation  efforts  have 
been  spent. 

•  Simplicity  and  intuitive  appeal  of  the  formalism.  The  formalism  involved — namely 
rewriting  logic  [32]  — is  very  simple  and  it  is  very  well  suited  for  specifying  distributed 
systems,  in  which  local  concurrent  transitions  can  be  specified  as  rewrite  rules. 

•  Modeling  flexibility.  Instead  of  building  in  a  fixed  model  of  concurrency,  rewriting  logic 
allows  great  flexibility  to  specify  many  such  models  [32,  34],  including  both  synchronous 
and  asynchronous  models  of  communication  and  a  wide  range  of  concurrent  object 
systems. 

•  Executability.  Rewriting  logic  specifications  are  executable  in  a  rewriting  logic  language 
such  as  Maude  [2].  This  means  that  the  formal  model  of  the  protocol  becomes  an 
executable  prototype  that  can  be  directly  used  for  simulating,  testing,  and  debugging  the 
specification. 

•  Wide-spectrum.  The  general  idea  is  to  have  a  series  of  increasingly  stronger  methods,  to 
which  a  system  specification  is  subjected.  Only  after  less  costly  and  “lighter”  methods 
have  been  used,  leading  to  a  better  understanding  and  to  important  improvements  and 
corrections  of  the  original  specification,  is  it  meaningful  and  worthwhile  to  invest  effort 
on  “heavier”  and  costlier  methods.  Our  approach  is  based  on  the  following,  increasingly 
stronger  methods:  execution  of  the  specification;  symbolic  simulation  and  narrowing 
analysis  to  explore  more  possible  computations;  model  checking  analysis  to  exhaustively 
search  a  finite  search  space  or  portions  of  an  infinite  one;  and  formal  proof  for  critical 
properties. 

We  have  used  the  Maude  environment  and  its  wide-spectrum  methodology  in  a  wide  variety  of 
case  studies  analyzing  active  networks  protocols,  languages,  and  active  packet  programs.  These 
case  studies  addressed  a  number  of  challenging  formalization  problems  including  modeling  net 
work  resources,  network  congestion,  and  real-time  properties  and  composition  of  protocols.  Our 
experience  has  been  very  positive,  demonstrating  that  Maude  can  substantially  help  in  modeling, 
symbolically  simulating,  and  analyzing  such  subsystems  of  active  networks  and  other 
communication  systems,  in  documenting  and  ensuring  consistency  of  important  parts  of  the 
architecture,  and  in  formalizing  and  analyzing  important  safety-critical  aspects.  We  were  able  to 
find  important  mistakes  and  omissions  in  early  design  stages,  and  in  informal  specifications  of 
already-deployed  systems. 
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1.1  Applying  Maude  to  Active  Networks  and  Communication  Protocols 

In  collaboration  with  other  teams  working  on  aetive  networks,  on  communieation  and  seeurity 
protoeols,  and  on  arehiteeture  issues,  we  have  applied  Maude  to  formally  speeify  and  analyze 
aetive  networks  protoeols  and  algorithms,  seeurity  protoeols,  eomposable  eommunieation 
serviees,  and  distributed  software  arehitectures.  Below  is  a  brief  summary  of  the  results  of  these 
efforts.  The  two  most  recent  case  studies  are  diseussed  in  more  detail  in  later  sections. 

•  A  reliable  broadcast  protocol.  In  collaboration  with  the  group  led  by  J.J.  Gareia-Luna  at 
the  Computer  Communieations  Researeh  Group  at  the  University  of  California,  Santa 
Cruz  (UCSC),  exeeutable  speeifieations  of  the  design  of  a  new  reliable  broadeast 
protoeol  (RBP)  [15]  were  developed  in  Maude  [5]  The  proeess  of  formally  speeifying  the 
protoeol,  and  of  symbolically  executing  and  formally  analyzing  the  resulting 
speeifieation  using  model  eheeking  teehniques,  revealed  deadloeks  and  ineonsisteneies 
very  early  in  the  design  proeess,  before  the  protoeol  was  implemented.  The  validation 
and  eorreetion  eyele  led  to  substantial  improvements  to  the  protoeol  design.  Incomplete 
or  unspeeified  assumptions  about  the  behavior  of  the  protoeol  were  elarified,  resulting  in 
a  elear  formalization  of  the  basie  ideas  of  the  starting  informal  protoeol. 

•  Analysis  of  cryptographic  protocols.  We  have  applied  Maude  to  the  speeifieation  and 
analysis  of  eryptographie  protoeols  [7]  and  have  shown  how  our  model  eheeking 
techniques  ean  be  used  to  diseover  attacks.  The  positive  experienee  modeling  and 
analyzing  seeurity  protoeols  in  Maude  [7]  has  led  to  the  use  of  Maude  by  J.  Millen  and  G. 
Denker  in  the  TIPE  DARPA  projeet  for  several  purposes.  First,  the  translation  from 
CAPSL  (Common  Authentication  Protocol  Specification  Language)  [9]  to  the  CAPSL 
Intermediate  Language  (CIL)  [9]  has  been  earried  out  in  Maude.  Seeond,  Maude  is  used 
as  a  model  eheeking  tool  in  the  integrated  protoeol  environment  and  toolkit.  The  CIL 
output  of  a  eryptographie  protoeol  is  translated  (in  Maude)  into  an  executable  Maude 
speeifieation.  A  meta-level  seareh  strategy  imports  the  Maude  protoeol  speeifieation  and 
provides  the  user  with  a  predefined  breadth-first  strategy. 

•  Specifying  and  analyzing  a  PLAN  algorithm.  PLAN  (Packet  Language  for  Aetive 
Networks)  [19]  is  a  language  to  program  active  networks  developed  at  the  University  of 
Pennsylvania  (UPenn).  In  eollaboration  with  Y.  Wang  and  C.  Gunter  at  UPenn,  we  have 
used  Maude  to  formally  specify  and  analyze  a  PLAN  active  network  algorithm  in  whieh 
active  paekets  seout  the  nodes  of  an  active  network  from  a  souree  to  a  destination  to  find 
an  optimal  route  relative  to  a  given  metrie  [45].  A  Maude  strategy  was  written  to  explore 
all  behaviors  from  a  given  initial  state  and  to  eheek  their  eorreetness,  using  the  faet  that 
the  algorithm  always  terminates. 

•  Middleware  architecture.  In  [6]  we  present  an  exeeutable  speeifieation  of  a  general 
middle-  ware  arehiteeture  for  eomposable  distributed  communieation  services  sueh  as 
fault  toleranee  and  seeurity  that  ean  be  eomposed  and  ean  be  dynamieally  added  to 
seleeted  subsets  of  a  distributed  eommunieations  system. 

•  Real-time  Maude.  The  Real-Time  Maude  tool  [40,  37]  supports  the  speeifieation  and 
analysis  of  real-time  rewrite  theories  in  timed  modules  and  objeet-oriented  timed 
modules  [41].  A  variety  of  search  and  model  eheeking  eommands  for  analyzing  timed 
modules  are  provided,  ineluding  facilities  for  model  eheeking  certain  classes  of  pattern- 
based  real-time  temporal  formulas  [40]. 


3 


•  Network  simulation  strategies  in  Maude.  Another  application  of  Maude  to  the 
specification  of  real-time  distributed  systems  is  the  specification  of  a  general  network 
model  in  Maude  and  primitives  for  defining  simulation  strategies  [30]  The  use  of  the 
model  has  been  illustrated  in  an  ongoing  case  study  based  on  the  IETF  PIM-DM 
(Protocol  Independent  Multi-Cast-  Dense  Mode)  draft,  and  on  a  pseudo-code 
specification  obtained  from  Brad  Smith  at  UC  Santa  Cruz. 

•  Specifying  the  AER/NCA  Protocol  Suite.  In  collaboration  with  Mark  Keaton  and  Steve 
Zabele  at  TASC,  the  Real-Time  Maude  tool  has  been  used  for  the  specification  and 
analysis  of  the  Active  Error  Recovery/Nominee-based  Congestion  Avoidance 
(AER/NCA)  suite  of  adaptive  multicast  congestion  control,  and  error  recovery  active 
network  protocols  developed  at  the  University  of  Massachusetts  (UMass)  and  TASC  [39, 
37].  AER/NCA  posed  several  challenging  new  problems,  including  formal  modeling  of 
time-sensitive  and  resource-  sensitive  behavior  and  the  composability  of  its  components. 
Several  subtle  errors  and  omissions  in  the  informal  use-case  specification  were 
uncovered. 

•  Formal  specification  of  PLAN  in  Maude.  The  PEAN  language  has  a  rigorous  but  informal 
operational  specification  [26].  In  collaboration  with  Carl  Gunter  and  Pankaj  Kakkar  at 
UPenn,  a  Maude  specification  of  a  substantial  subset  of  the  PLAN  language  has  been 
developed  [44]  Since  the  specification  is  executable,  it  can  be  used  for  testing  and 
simulation  of  PLAN  programs.  It  also  eliminates  the  need  for  hand  translation  of  PLAN 
programs  into  Maude  in  order  to  analyze  them.  A  polymorphic  type  inference  system  for 
PLAN  programs  has  been  written  in  Maude,  and  a  specialization  transformation  has  been 
designed  that  simplifies  simulation,  testing,  and  reasoning  about  PLAN  programs  in 
Maude. 

2  Rewriting  Logic  and  Maude  Basics 

Rewriting  logic  [32]  is  a  very  simple  logic  that  is  well  suited  as  a  framework  for  formal 
specification  and  analysis  of  distributed  systems.  Both  the  distributed  states  and  the  local 
concurrent  transitions  of  such  systems  can  be  naturally  specified  by  rewrite  theories  (X,  E,  R)  in 
which  such  local  concurrent  transitions  are  described  by  rewrite  rules  R.  Specifically,  the 
distributed  state  can  be  axiomatized  as  an  algebraic  data  type  by  an  equational  theory  (X,  E),  and 
each  rewrite  rule  t  ^t'  in  7?  is  interpreted  as  a  local  transition  in  the  distributed  state  of  the 
system.  That  is,  t  and  t'  describe  patterns  for  fragments  of  the  distributed  state  of  a  system,  and 
the  rule  specifies  how  a  local  concurrent  transition  can  take  place  in  such  a  system,  changing  the 
local  state  fragment  from  the  pattern  t  to  the  pattern  t' .  Rewriting  logic  then  provides  a  simple 
inference  system  in  which  one  can  derive  all  the  possible  finitary  concurrent  transitions  of  the 
system  so  axiomatized.  That  is,  concurrent  computations  exactly  correspond  to  deductions  in  the 
logic. 

As  a  wide-spectrum  semantic  framework,  rewriting  logic  is  well  suited  to  span  the  gap  between 
high-level  properties  and  architectural  designs  on  the  one  hand,  and  distributed  or  mobile  system 
implementations  on  the  other.  Rewriting  logic  has  been  used  to  give  a  precise  semantics  to  a 
number  of  distributed  architectural  notations  and  concepts,  and  to  obtain  partially-  or  fully- 
defined  formal  executable  specifications  from  such  notations  [35]  Using  Maude  and  its 
associated  tools  [2]  such  executable  specifications  can  then  be  analyzed  in  a  variety  of  ways, 
including  symbolic  simulation  and  debugging,  and  flexible  forms  of  model  checking  analysis. 
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Furthermore,  using  model  checking  analysis  and  formal  proofs,  high-level  properties  of  such 
specifications  ex  pressed  in  nonexecutable  formalisms  such  as  temporal  and  modal  logics  can 
likewise  be  analyzed  and  verified.  Since  rewriting  logic  specifications  can  under  quite  reasonable 
assumptions  be  directly  implemented  with  competitive  performance  as  distributed  and  mobile 
systems,  it  is  possible  to  span  the  gap  from  high-level  designs  to  distributed  implementations 
without  leaving  the  formal  framework. 

3  Specification  and  Anaiysis  of  the  AER/NCA  Protocoi  Suite 

The  Real-Time  Maude  tool  [40]  and  the  Maude  formal  methodology  [8]  has  been  applied  to  the 
specification  and  analysis  of  the  AERINCA  suite  of  active  network  communication  protocol 
components  [27,  1],  which  collectively  implement  a  scalable  and  reliable  multicast  capability 
using  active  elements  in  the  network.  Being  a  very  advanced  and  sophisticated  suite  of  protocols 
that  run  in  a  highly  distributed  and  modular  fashion,  the  AER/NCA  suite  poses  challenging  new 
problems  for  formal  specification  and  analysis  including: 

•  Time-sensitive  behavior:  including  delay,  delay  estimation,  timers,  ordering,  and  resource 
contention; 

•  Resource-sensitive  behavior:  capacity,  latency,  congestion/cross-traffic,  and  buffering; 

•  Critical  metrics:  performance  and  correctness; 

•  Composability  issues:  modeling  and  analyzing  both  individual  protocol  components  and 
their  aggregate  behavior,  and  supporting  reuse  for  developing  alternative  protocols. 

With  invaluable  help  from  Mark  Keaton  and  Steve  Zabele  at  TASC,  who  provided  informal 
specifications  and  answered  all  our  questions,  we  formally  specified  and  analyzed  the  AER/NCA 
in  Real-Time  Maude,  a  tool  extending  Maude  to  support  the  area  of  distributed  real-time  and 
hybrid  systems  [40,  37]. 

Real-Time  Maude  has  proved  to  be  well  suited  to  meeting  the  above  challenges.  The  active 
network  and  performance  aspects  have  been  naturally  addressed  by  the  flexibility  of  Maude’s 
distributed  object  model  [33]  that  made  it  easy  to  include  active  elements  and  resources  as 
objects.  The  time-  and  resource-sensitive  behavior  is  expressed  naturally  by  timed  rewrite  rules. 
The  compos  ability  issues  were  well  addressed  by  Maude’s  support  for  multiple  class 
inheritance. 

3.1  Rapid  Prototyping  and  Formai  Anaiysis  in  Reai-Time  Maude 

The  Real-Time  Maude  specification  language  and  analysis  tool  [37,  40]  is  built  on  top  of  Maude. 
Real-Time  Maude  supports  the  specification  of  real-time  rewrite  theories  in  timed  modules  and 
object-oriented  timed  modules,  which  are  transformed  into  equivalent  Maude  modules.  The  Real 
Time  Maude  tool  supports  a  wide  range  of  techniques  for  formally  analyzing  timed  modules,  as 
we  summarize  below. 

3.1.1  Rapid  Prototyping 

The  Real-Time  Maude  tool  transforms  timed  modules  into  ordinary  Maude  modules  that  can  be 
immediately  executed  using  Maude’s  default  interpreter,  which  simulates  one  behavior — up  to  a 
given  number  of  rewrite  steps  to  perform — from  a  given  initial  state.  The  tool  also  has  a  default 
timed  execution  strategy  that  controls  the  execution  by  taking  the  elapsed  time  in  the  rewrite  path 
into  account. 
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3.1.2  Model  Checking 

Real-Time  Maude  provides  a  variety  of  seareh  and  model  eheeking  eommands  for  further 
analyzing  timed  modules  by  exploring  all  possible  behaviors — up  to  a  given  number  of  rewrite 
steps,  duration,  or  satisfaetion  of  other  eonditions — that  ean  be  nondeterministieally  reaehed 
from  the  initial  state.  In  partieular,  the  tool  provides  model  eheeking  faeilities  for  model 
eheeking  eertain  elasses  of  real-time  temporal  formulas  [40]  In  the  following,  we  will  treat 
temporal  properties  of  the  form  p  UStable<rp',  where  p  and  p'  are  patterns,  and  UStable<r  is  a 
temporal  “until/stable”  operator.  A  pattern  is  either  the  eonstant  noTerm  (whieh  is  not  matehed 
by  any  term),  the  eonstant  anyPattem  (whieh  is  matehed  by  any  term),  a  term  (possibly) 

eontaining  variables,  or  has  the  form  t(x)  where  cond  ( x  ).  The  temporal  property  p  UStable<r  p' 
is  satisfied  by  a  real-time  rewrite  theory  with  respeet  to  an  initial  term  to  if  and  only  if  for  eaeh 
infinite  sequenee  and  eaeh  nonextensible  finite  sequenee 

of  one-step  sequential  ground  rewrites  [32]  in  the  transformed  “eloeked”  rewrite  theory  [39] 
there  is  a  A:  with  r  sueh  that  matehes  p ',  and  t  matehes  p  for  all  0  <  /  <  k,  and,  furthermore, 

if  tj  matehes  p'  then  so  does  ti  for  eaeh  1  >  j  with  <  r.  That  is,  eaeh  state  in  a  eomputation 
matehes  p  until  p’  is  matehed  for  the  first  time  (by  a  state  with  total  time  elapse  less  than  or  equal 
to  r),  and,  in  addition,  p'  is  matehed  by  all  subsequent  states  with  total  time  elapse  less  than  or 
equal  to  r. 

3.1.3  Application-Specific  Analysis  Strategies. 

A  Real-Time  Maude  speeifieation  ean  be  further  analyzed  by  using  Maude’s  refleetive  features 
to  define  applieation-speeifie  analysis  strategies.  For  that  purpose,  Real-Time  Maude  provides  a 
library  of  strategies — ineluding  the  strategies  needed  to  exeeute  Real-Time  Maude’s  seareh  and 
model  eheeking  eommands — speoifieally  designed  for  analyzing  real-time  speeifieations. 

3.2  The  AER/NCA  Protocol  Suite 

The  AER/NCA  protoeol  suite  [1,  27]  is  a  new  and  sophistieated  protoeol  suite  for  reliable 
multieast  in  aetive  networks.  The  suite  eonsists  of  a  oolleetion  of  eomposable  protoeol 
eomponents  supporting  aetive  error  reeovery  (AER)  and  nominee-based  eongestion  avoidanee 
(NCA)  features,  and  makes  use  of  the  possibility  of  having  some  proeessing  eapabilities  at 
“aetive  nodes”  between  the  sender  and  the  reeeivers  to  aehieve  sealability  and  effieieney. 

The  goal  of  reliable  multieast  is  to  send  a  sequenee  of  data  paekets  from  a  sender  to  a  group  of 
reeeivers.  Paekets  may  be  lost  due  to  eongestion  in  the  network,  and  it  must  be  ensured  that  eaeh 
reeeiver  eventually  reeeives  eaeh  data  paeket.  Existing  multieast  protoeols  are  either  not  sealable 
or  do  not  guarantee  delivery.  To  aehieve  both  reliability  and  scalability,  Kasera  et  al.  [27]  have 
suggested  the  use  of  active  services  at  strategic  locations  inside  the  network.  These  active 
services  can  execute  application-level  programs  inside  routers,  or  on  servers  colocated  with 
routers  along  the  physical  multicast  distribution  tree.  By  caching  packets,  these  active  services 
can  subcast  lost  packets  directly  to  “their”  receivers,  thereby  localizing  error  recovery  and 
making  error  recovery  more  efficient.  Such  an  active  service  is  called  a  repair  server.  If  a  repair 
server  does  not  have  the  missing  packet  in  its  cache,  it  aggregates  all  the  negative 
acknowledgments  (NAKs)  it  receives,  and  sends  only  one  request  for  the  lost  packet  toward  the 
sender,  solving  the  problem  of  feedback  implosion  at  the  sender. 
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3.2.1  Informal  Description  of  the  Protocoi 

The  protocol  suite  consists  of  the  following  four  composable  components: 

•  The  repair  service  (RS)  component  deals  with  packet  losses  and  tries  to  ensure  that  each 
packet  is  eventually  received  by  each  receiver  in  the  multicast  group. 

•  Rate  control  (RC):  The  loss  of  a  substantial  number  of  packets  indicates  over-congestion 
due  to  too  high  a  frequency  in  the  sending  of  packets.  The  rate  control  component 
dynamically  adjusts  the  rate  by  which  the  sender  sends  new  packets,  so  that  the  frequency 
decreases  when  many  packets  are  lost,  and  increases  when  few  packet  losses  are  detected. 

•  Finding  the  nominee  receiver  (NOM):  The  sender  needs  feedback  about  discovered 
packet  losses  to  adjust  its  sending  rate.  However,  letting  all  receivers  report  their  loss 
rates  would  result  in  too  many  messages  being  sent  around.  The  protocol  tries  to  find  the 
“worst”  receiver,  based  on  the  loss  rates  and  the  distance  to  the  sender.  Then  the  sender 
takes  only  the  losses  reported  from  this  nominee  receiver  into  account  when  determining 
the  sending  rate. 

•  Finding  round  trip  time  values  (RTT):  To  determine  the  sending  rate,  the  nominee,  and 
how  frequently  to  check  for  missing  packets,  knowledge  about  the  various  round  trip 
times  (the  time  it  takes  for  a  packet  to  travel  from  a  given  node  to  another  given  node, 
and  back)  in  the  network  is  needed. 

These  four  components  are  defined  separately,  each  by  a  set  of  use  cases,  in  the  informal 
specification  [1]  and  are  explained  in  [37,  27].  In  our  formal  specification  the  rewrite  rules 
closely  correspond  to  the  use  cases. 

3.3  Formal  Specification  of  the  AERJNCA  Protocoi  Suite  in  Real-Time  Maude 

The  Real-Time  Maude  specification  of  the  AERINCA  protocol  suite,  summarized  here,  is  de 
scribed  in  its  entirety  in  [37,  38].  Although  the  four  protocol  components  are  closely  interrelated, 
it  is  nevertheless  important  to  analyze  each  component  separately,  as  well  as  in  combination. 

3.3.1  Modeling  Communication  and  the  Communication  Topology 

We  abstract  away  from  the  passive  nodes  in  the  network,  and  model  the  multicast 
communication  topology  by  the  multicast  distribution  tree,  which  has  the  sender  as  its  root,  the 
receivers  in  the  multicast  group  as  its  leaf  nodes,  and  the  repair  servers  as  its  internal  nodes. 
Appropriate  classes  for  these  objects  are  defined  in  their  Real-Time  Maude  specification  [37]. 

Packets  are  sent  through  links,  which  model  edges  in  a  multicast  distribution  tree.  The  time  it 
takes  for  a  packet  to  arrive  at  a  link’s  target  node  depends  on  the  size  of  the  packet,  the  number 
of  packets  already  in  the  link,  and  the  speed  and  propagation  delay  of  the  link.  All  these  factors 
affect  the  degree  of  congestion  and  must  be  modeled  to  faithfully  analyze  the  AERINCA 
protocol.  The  class  LINK  models  all  these  aspects.  The  attempt  to  enter  a  packet  p  into  the  link 
from  a  to  Z)  is  modeled  by  the  message  send  (p,  a,  b).  This  message  is  handled  by  the  link 
from  fl  to  h  by  discarding  the  packet  if  the  link  is  full,  and  otherwise  by  delivering  it — after  a 
delay  corresponding  to  the  transmission  delay — by  sending  the  message  p  from  a  to  b  to  the 
global  configuration,  where  it  should  then  be  handled  by  object  b. 
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3.3.2  The  Class  Hierarchy 

The  Real-Time  Maude  speeifieation  is  designed  using  multiple  elass  inheritanee,  so  that  eaeh  of 
the  four  protoeol  eomponents  RTT,  NOM,  RC,  and  RS  ean  be  exeeuted  separately  as  well  as 
together  in  eombination.  Figure  1  shows  the  elass  hierarehy  for  sender  objeets,  whieh  allows  for 
maximal  reuse  of  transitions  that  have  the  same  behavior  when  a  component  is  executed 
separately  and  when  it  is  executed  together  with  the  other  components.  The  class  hierarchies  for 
repair  servers  and  receivers  are  entirely  similar. 

3.3.3  Specifying  the  Receiver  in  the  Repair  Service  Protocol 

To  exemplify  the  Real-Time  Maude  specification  style,  we  present  some  parts  of  the 
specification  of  the  receiver  objects  in  the  RS  protocol.  The  receiver  receives  data  packets  and 
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RTTsender  NOMsender  RCsender  RSsender 
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RTTsenderAlone  NOMsenderAlone  RCsenderAlone  RSsenderAlone 


Figure  1.  The  Sender  Class  Hierarchy 


forwards  them  to  the  receiver  application  in  increasing  order  of  their  sequence  numbers. 
Received  data  packets  that  cannot  be  forwarded  to  the  application,  because  some  data  packets 
with  lower  sequence  numbers  are  missing,  are  stored  in  the  dataBuffer  attribute,  and  the 
smallest  sequence  number  among  the  nonreceived  data  packets  is  stored  in  the  readNext  Seq 
attribute.  When  the  receiver  detects  the  loss  of  a  data  packet,  it  waits  a  small  amount  of  time  (in 
case  some  of  its  “siblings”  or  its  repair  server  also  have  detected  the  loss)  before  sending  a 
NAK-request  for  the  lost  packet  to  its  repair  server.  The  repair  server  then  either  subcasts  the 
data  packet  from  its  cache  or  forwards  the  request  upstream.  The  receiver  retransmits  its  request 
for  the  missing  data  packet  if  it  does  not  receive  a  response  to  the  repair  request  within  a 
reasonable  amount  of  time.  We  store,  for  each  missing  data  packet,  the  information  about  the 
recovery  attempts  for  the  missing  data  packets  in  a  term 

inio(seqNo,  supprTimer,  retransTimer,  NAKcount), 

where  seqNo  is  the  sequence  number  of  the  data  packet,  supprTimer  is  the  value  of  the 
suppression  timer  for  the  data  packet  (this  value  is  either  the  value  noTimeValue  when  the 
timer  is  turned  off,  or  the  time  remaining  until  the  timer  expires),  retransTimer  is  the  value  of  the 
retrans  mission  timer  of  the  data  packet,  and  NAKcount  is  the  NAK  count  of  the  data  packet, 
denoting  how  many  times  a  repair  for  the  data  packet  has  been  attempted.  Elements  of  a  sort 
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Datalnfo  are  multisets  of  info  terms,  where  multiset  union  is  denoted  by  an  assoeiative  and 
eommutative  juxtaposition  operator. 

The  reeeiver  class  RSreceiver  in  the  RS  component  is  declared  as  shown  below.  Each  of  the 
attributes  of  objects  in  the  class  is  declared  with  its  type  (sort).  For  example,  the  attribute 
fastRepairFlag  has  type  Bool.  The  class  RSreceiver  is  declared  as  a  subclass  of  Receiver. 

class  RSreceiver  I 

fastRepairFiag  :  Bool, 
readNextSeq :  NzNat, 
retransTO  :  Time, 
dataBuffer  :  MsgConf, 

datalnfo :  Datalnfo  . 
subclass  RSreceiver  <  Receiver  . 

As  an  example  of  the  modeling  of  the  use  cases  in  the  informal  specification,  we  show  the  use 
case  and  corresponding  mle  that  describes  what  happens  when  the  suppression  timer  for  a 
missing  data  packet  expires,  that  is,  when  the  second  parameter  of  an  info- term  is  0.  The  use 
case  in  the  informal  AER/NCA  specification  is  given  as  follows: 

B.5  This  use  case  begins  when  the  NAK  suppression  timer  for  a  missing  data  packet 
expires.  The  following  processing  is  performed  (seq  is  the  sequence  number  of 
the  missing  data  packet) : 

if  ( (data  packet  seq  is  currently  buffered)  OR  (seq  <  readNextSeq)) 

{  End  Use  Case  } 

if  (NAK  count  for  data  packet  seq  >  48) 

{  Error,  connection  is  broken,  cannot  continue  } 

Unicast  a  NAK  packet  for  data  packet  seq  with  the  receiver's  NAK 
count  and  fastRepairFiag  to  repair  Server 
Start  a  NAK  retransmission  timer  for  data  packet  seq  with  a 
duration  of  retransTO 

This  use  case  is  modeled  in  Real-Time  Maude  by  the  following  rewrite  mle,  which  specifies  how 
an  object  of  class  RSreceiver  behaves  under  the  circumstances  informally  described  by  the  use 
case.  The  variable  declarations  preceding  the  rewrite  mle  state  the  type  assumed  for  variables 
used  in  the  mle. 


***  first  missing  data  packet 

***  time  before  resending  NAK  packet 

***  buffered  dataPackets 

store  info  about  repairs 
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vars  Q  Q'  :  Oid  .  vars  NZN  NZN'  :  NzNat  .  var  X  :  Bool  . 
var  MC  :  MsgConf  .  vars  DI  DI '  :  Datainfo  .  var  N  :  Nat  . 
var  DT  :  DefTime  .  var  CF  :  Configuration  .  var  R  :  Time  . 
op  ERROR  :  ->  Configuration 

rl  [B5]  : 

{<  Q  :  RSreceiver  |  readNextSeq  :  NZN,  f astRepairFlag  :  X, 

dataBuffer  :  MC,  repairserver  Q'  ,  retransTO  :  R, 
datainfo  :  (info  (NZN'  ,  0,  DT,  N)  DI)  >  CF  } 

=> 

{if  (NZN'  seqNoIn  MC)  or  (NZN'  <  NZN)  then 

(<  Q  :  RSreceiver  |  datainfo  :  (info (NZN',  noTimeValue,  DT,  N)  DI)  >  CF) 
else  (if  48  <  N  then  ERROR 

else  (<  Q  :  RSreceiver  |  datainfo  : 

(info (NZN'  ,  noTimeValue,  R,  N)  DI)  > 
send (NAKPacket  (NZN'  ,  N,  X),  Q,  Q')  CF)  fi)  fi}  . 


The  functions  mte  and  delta  define  the  timed  behavior  of  objects  of  class  RSreceiver  Alone. 
The  only  time-dependent  values  are  the  two  timers  in  the  information  state  for  each  missing  data 
packet.  The  function  mte  ensures  that  the  “tick  mle”  in  [37]  stops  the  time  advance  when  a  timer 
expires,  and  the  function  delta  updates  the  timers  according  to  the  time  elapsed. 

3.4  Formal  Analysis  of  the  AER/NCA  Protocol  Suite  in  Real-Time  Maude 

The  AER/NCA  protocol  has  been  subjected  to  rapid  prototyping  and  formal  analysis,  as 
illustrated  here  and  described  in  full  detail  in  [37]. 

3.4.1  Rapid  Prototyping. 

To  execute  the  repair  service  protocol  we  added  a  sender  application  object  and  a  number  of 
receiver  application  objects,  and  defined  an  initial  state  RSstate.  The  sender  was  supposed  to  use 
the  protocol  to  multicast  21  data  packets  to  the  receiver  applications.  Rewriting  this  initial  state 
should  have  led  to  a  state  where  all  receiver  applications  had  received  all  packets.  Instead,  the 
execution  uncovered  an  ERROR  state.  By  executing  fewer  rewrites  we  could  follow  the 
execution  leading  to  the  ERROR  state,  and  could  easily  find  the  errors  in  the  formal  and 
informal  specifications.  Executing  the  repair  service  protocol  with  a  different  initial  state 
revealed  another  undesirable  behavior  where  a  lost  packet  was  never  repaired,  and  we  could 
again  easily  trace  the  error. 

The  other  protocol  components  have  been  prototyped  by  executing  appropriate  initial  states  and 
exhibit  the  expected  behavior.  The  composite  protocol  was  executed  with  the  initial  state  having 
the  same  topology  as  the  one  for  which  execution  of  the  stand-alone  RS  protocol  failed. 
However,  the  composite  protocol  managed  to  deliver  all  data  packets  to  each  receiver.  This  was 
due  to  the  presence  of  the  rate  control  component,  which  adjusted  the  sending  rate  to  avoid  the 
packet  losses  that  led  to  the  faulty  behavior  in  the  execution  of  the  RS  protocol  component. 

3.4.2  Formal  Analysis 

The  specifications  were  subjected  to  further  formal  analysis  by  using  the  search  and  model  check 
ing  commands  and  the  meta-programming  features  of  Real-Time  Maude.  Eor  example,  the  RTT 
protocol  should  find  in  the  sourceRTT  attribute  the  round  trip  times  from  each  node  to  the 
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sender.  Likewise,  eaeh  reeeiver  or  repair  server  should  have  a  maxUpRTT  value  equal  to  the 
maximal  round  trip  time  from  any  of  its  “siblings”  to  its  immediate  upstream  node.  The  main 
property  that  the  stand-alone  RTT  protoeol  should  satisfy  is  that,  as  long  as  at  most  one  paeket 
travels  in  the  same  direetion  in  the  same  link  at  the  same  time,  the  following  properties  hold: 

•  Eaeh  rewrite  path  will  reaeh  a  state  with  the  desired  sourceRTT  and  maxUpRTT  values 
within  given  time  and  depth  limits  (reaehability). 

•  Onee  these  desired  values  have  been  found,  they  will  not  ehange  within  the  given  time 
limit  (stability). 

We  defined  an  initial  test  eonfiguration  RTTstate  with  nodes  'a,  'b,  ...,  'g,  and  where,  in 
otherwise  empty  links,  the  round  trip  times  to  the  souree  from  the  nodes  'c,  'd,  and  'e  are, 
respeetively,  58,  106,  and  94,  and  the  maxUpRTT  values  of  these  nodes  are,  respeetively,  58,  48, 
and  48.  States  in  whieh  the  nodes  'c,  'd,  and  'e  have  the  above  sourceRTT  and  maxUpRTT 
values  are  matehed  by  the  pattern 

{  <  'c  :  RTTrepairserverAlone  I  sourceRTT  :  58,  maxUpRTT  :  58,  ATTSl  > 

< 'd  :  RTTrepairserverAlone  I  sourceRTT  :  106,  maxUpRTT  :  48,  ATTS2  > 

<  'e  :  RTTreceiver Alone  I  sourceRTT  :  94,  maxUpRTT  :  48,  ATTS3  >  CF}. 


where  ATTSl,  ATTS2,  ATTS3,  and  CF  are  variables  used  to  mateh  the  remaining  attributes  and 
objeets. 

The  desired  property  that  the  RTT  protoeol  should  satisfy  ean  therefore  be  given  by  the 
following  temporal  formula,  where  P  abbreviates  the  above  pattern 

anyPattern  UStable  <timeLimit  P . 

To  eheek  this  property  we  used  Real-Time  Maude’s  strategy  library  to  define  a  model  eheeking 
funetion 

ustable(mod,  tg,  n,  HmeLimit ,  pattern) 

whieh  gives  the  set  of  terms  representing  rewrite  paths  using  the  module  mod,  starting  from  the 
initial  term  whieh  invalidate  the  reaehability-and-stability  property 

anyPattern  \JStahle<timeLimit  pattern, 

and  whieh  have  maximal  bound  n  on  the  number  of  rewrites  in  the  path  (with  0  meaning 
unbounded).  The  seareh  returns  emptyTermSet  if  the  property  holds  for  all  paths  satisfying  the 
given  length  bound. 

We  used  the  ustable  funetion  to  eheek  whether  the  above  desired  property  holds  in  all  rewrite 
paths  having  total  time  elapse  less  than  or  equal  to  400,  starting  from  state  RTTstate.  All  paths 
found  satisfied  the  desired  property,  thus  inereasing  our  eonfidenee  in  the  eorreetness  of  the 
proto  eol. 
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The  search  function  us  table  has  also  been  used  to  show  the  undesired  property  that  there  is  a 
behavior — after  some  receiver  has  been  nominated  and  is  aware  of  it — in  which  no  receiver  has 
its  isNominee  flag  set  to  true.  This  property  can  be  shown  by  finding  a  counterexample  to  the 
opposite  claim,  namely,  anyPattern  UStable<„  pattern  P',  where  P'  is  the  pattern 

<  Q  :  NOMreceiverAlone  I  isNominee  ;  true,  ATTS1  >  CF 

matched  by  receivers  whose  nominee  flag  is  set  to  true.  The  property  anyPattern  UStable<„ 
pattern  P'  does  not  hold.  Checking  this  property  using  ustable  resulted  in  a  useful 
counterexample. 

3.5  Experience  Gained  from  the  AER/NCA  Anaiysis 

The  AER/NCA  protocol  suite  stressed  the  Real-Time  Maude  tool  and  Maude  formal 
methodology  with  a  challenging  distributed  real-time  application.  Real-Time  Maude  proved  to 
be  a  good  match  for  this  challenge.  All  of  the  errors  previously  found  (but  not  initially  disclosed 
to  the  Maude  team)  by  testing  and  AER/NCA  implementation  using  NS,  and  active  networks  test 
beds,  were  found  with  modest  effort  using  the  Real-Time  Maude  environment.  In  addition, 
previously  unknown  errors  were  found  as  a  result  of  the  Maude  effort.  Two  key  issues  for 
adequate  formalization  and  analysis  are  the  appropriateness  and  usefulness  of  the  resulting 
specification,  and  the  adequacy  of  the  tool  support.  In  particular,  the  formalization  needs  to  be  at 
the  right  level  of  abstraction  to  represent  the  essential  features — including  in  this  case  resource 
contention  and  real-time  behavior — without  being  overwhelmed  by  the  complex  nature  of  the 
system  being  modeled.  In  this  regard,  the  modularity  and  composability  of  the  specifications  for 
each  component  made  it  easy  to  understand  and  analyze  individual  components  and  aggregate 
system  behaviors.  Eurthermore,  the  flexibility  and  extensibility  of  the  Real-Time  Maude  strategy 
library  made  it  easy  to  carry  out  complex  analyses  tailored  to  the  specific  application  that  would 
have  been  infeasible  using  general-purpose  algorithms. 

The  adequacy  of  the  Real-Time  Maude  specification  for  applications  of  this  nature  can  be 
contrasted  with  that  of  use  cases,  such  as  those  in  the  informal  specification  provided  by  the 
TASC  Team  which  was  the  starting  point  of  our  formal  specification  effort.  Although  use  cases 
are  widely  used  as  a  software  design  technique,  the  experience  gained  from  the  present  work 
indicates  that  they  are  not  well  suited  for  modeling  complex  distributed  systems.  To  understand 
the  system  behavior,  state  transition  diagrams  had  to  be  developed  by  the  protocol  designers.  The 
Maude  specification  provided  a  natural  formalization  of  the  informal  state  transition  diagrams 
and  followed  closely  the  designers’  intuitions.  In  hindsight,  it  seems  clear  that,  for  distributed 
applications  of  this  kind,  the  executable  state-transition  style  of  the  Maude  specification  is  a 
much  more  effective  starting  point  for  an  implementation  than  use  cases. 

4  The  Semantics  of  PLAN  in  Maude 

One  of  the  areas  of  active  networks  research  is  the  development  of  programming  paradigms  that 
provide  a  suitable  level  of  abstraction  for  active  networks  applications.  A  particular 
programming  language  providing  such  a  new  paradigm  is  PLAN,  the  Packet  Language  for 
Active  Networks  [19,  18,  36,  20,  26],  which  has  been  implemented  as  part  of  PLANet,  an  active 
internetwork  architecture  [21].  PLAN  is  a  resource-bounded  functional  programming  language 
that  uses  a  form  of  remote  procedure  call  to  realize  active  network  packet  programming.  PLAN 
programs  are  sets  of  active  packets  that  travel  through  a  network,  executing  code  on  specified 
nodes.  Remote  function  execution  means  that  functions  can  be  applied  to  arguments  so  that  the 
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execution  does  not  take  place  locally  but  in  the  execution  environment  of  a  different  network 
node.  To  this  end,  the  function  call  is  treated  as  a  so-called  chunk,  that  is,  as  a  piece  of  data, 
which  is  transmitted  to  the  destination  node  by  means  of  a  packet.  Resource  awareness  refers  to  a 
mechanism  that  keeps  track  of  computational  resources  to  ensure  that  all  PLAN  programs  are 
terminating.  In  addition,  PLAN  programs  interact  with  their  host  nodes  through  Service  Package 
interfaces.  Basic  services  include  provision  of  information  about  local  network  topology,  local 
node  properties,  time,  and  routing.  Additional  possible  services  include  resident  data  services  for 
(time-limited)  data  storage  and  retrieval.  Details  can  be  found  in  the  PLAN  programmer’s  guide 
[22]. 

The  active  nature  of  PLAN  programs  makes  it  important  to  have  a  formal  specification  of  the 
semantics.  Here  we  describe  the  case  study  in  which  we  developed  a  formal  semantics  of  the 
PLAN  active  network  language  in  Maude.  (A  Web  site,  for  which  the  Maude  Web  page  will 
have  a  link,  is  under  construction  from  which  the  case  study  will  be  accessible,  including  the 
Maude  modules,  documentation,  and  examples  using  the  specification — ^watch  the  Maude  Web 
page  for  a  link.)  Such  a  formal  specification  should  be  usable  by  a  diverse  community  of  users. 
In  addition  we  wanted  a  specification  that  supported  addressing  concerns  arising  from  different 
views  of  PLAN,  and  one  that  faithfully  captured  the  key  concepts  emerging  from  the  existing 
informal  and  semiformal  semantics. 

Concerning  the  potential  users  of  the  Maude  specification,  we  aimed  for  a  specification  that 
could  be  used  by: 

•  Implementors — as  a  reference  standard  with  a  flexible  notion  of  conformance 

•  Programmers — providing 

—  a  clear  and  intuitive  semantics  for  PLAN  constructs 

—  a  tool  for  prototyping  and  simulation 

—  a  basis  for  analyzing  and  proving  properties  of  PLAN  programs 

•  Language  designers — providing 

—  a  simple  formal  basis  for  reasoning  about  properties  of  the  language 

—  a  tool  for  experimenting  with  new  designs 

—  a  framework  for  specifying  safety  properties  of  the  service  packages 

—  a  basis  for  expressing  compiler/platform  independent  guarantees  for  network 

protection 

For  all  these  uses  it  is  important  to  express  the  underlying  network  model  and  the  program 
execution  model  at  the  right  level  of  abstraction.  Two  dimensions  of  desired  flexibility  for  PLAN 
implementations  are  (1)  the  degree  of  concurrency  and  (2)  anytime  type-checking.  Network-level 
concurrency  is  unavoidable;  each  node  executes  its  tasks  independently.  Node-level  concurrency 
is  under  the  control  of  the  implementation — several  packets  may  execute  concurrently  on  a  node, 
or  execution  may  be  completely  sequentialized.  Anytime  type-checking  means  that  runtime  type 
errors  must  be  avoided,  but  at  each  node  the  implementor  can  decide  how  they  are  to  be 
prevented:  by  purely  dynamic  checking  (stopping  execution  just  before  a  runtime  error),  purely 
static  checking  (not  allowing  a  program  to  execute  if  it  cannot  be  proved  to  be  well  typed),  or 
some  intermediate  strategy. 
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The  multiple  views  of  PLAN  and  assoeiated  eoncems  inelude: 

•  A  language  for  programming  mobile  agents  with  eoneerns  of  seeurity 

•  A  language  for  programming  networks  with  eoneerns  of  safety  and  resouree  usage 

•  A  seripting  language  for  eombining  services  provided  by  network  nodes,  that  is 
parametric  in  the  choice  of  node  services  and  uses  rely/guarantee-style  reasoning 

Our  sources  for  the  informal  semantics  of  PLAN  included  (in  addition  to  conversations  with 
members  of  the  Switchware  team)  the  PLAN  specification  document  [24]  and  paper  [26]  (a 
fairly  detailed  description  of  an  operational  semantics)  and  the  PLAN  programmers  guide  [22] 

We  have  specified  a  more  general  language  that  we  call  the  PLAN  Frame  Language. 
Generalizing  leads  to  a  simpler,  more  elegant  model.  PLAN  maps  naturally  to  a  subset  defined 
by  simple  syntactic  restrictions.  Our  specification  fully  captures  the  intent  of  the  specifications 
[24]  and  [25],  but  has  the  benefit  of  being  both  rigorously  formal  and  executable.  Furthermore, 
as  we  will  illustrate,  this  specification  can  be  used  at  very  different  levels  [8]  ranging  from 
execution  of  test  configurations  and  model  checking  analysis  to  verification  of  higher-level 
properties. 

4.1  Overview  of  PLAN  in  Maude 

In  our  Maude  specification  of  PLAN  the  structure  of  configurations  of  a  network  executing 
PLAN  packets  is  modeled  as  a  “soup”  (multiset)  of  nodes  and  packets  in  transit.  Each  node  is 
itself  represented  as  a  soup  consisting  of  a  core  node,  datasets  belonging  to  the  node,  and 
processes  belonging  to  the  node.  This  representation  of  the  high-level  structure  allows 
concurrency  to  be  represented  quite  naturally  using  multiset  rewriting. 

A  core  node  has  the  form  Node  (1,  devs,  nbrs,  rt)  where  1  is  the  node  identifier, 
devs  is  a  list  of  addresses  of  devices  interfacing  the  node  to  the  network,  nbrs  is  a  list  of 
neighbors  (reachable  by  one  hop),  and  rt  is  a  routing  table.  The  network  communication 
channels  are  not  explicitly  modeled,  and  the  network  topology  is  implicit  in  the  neighbors  lists. 

A  process  has  the  form  Process  ( 1 ,  src,  ariv,  ssn,  rb,  redstate)  where  1  is 
the  identifier  of  the  node  on  which  the  process  is  executing,  src  identifies  the  packet’s  original 
sending  node,  ariv  is  the  device  on  which  the  packet  arrived  at  the  node,  ssn  is  the  packet’s 
session  identifier,  rb  is  the  amount  of  resource  available  to  the  packet,  and  redstate  is  the 
state  of  the  abstract  machine  executing  the  packet  program.  To  specify  this  abstract  machine  we 
use  an  approach  developed  for  functional  languages  with  side  effects  [14,  23,  31].  The  main  idea 
is  that  the  local  reduction  state,  redstate,  of  a  process  is  a  pair  (cx,  ex)  consisting  of  a 
reduction  context,  cx,  (an  expression  with  a  hole)  and  the  expression,  ex,  to  be  reduced  in  this 
context.  Further  more,  the  specification  uses  the  CINNI  calculus  [43]  to  specify  binding  relations 
in  the  language.  This  approach  has  the  advantage  that  parameter  binding  can  be  represented  by 
substitution,  with  a  simple  mechanism  for  avoiding  the  problems  of  name  capture  and  renaming. 

A  packet  has  the  form  Packet  (nhop,  dest,  src,  ssn,  rb,  rf,  val,  vail) 
where  nhop  addresses  the  next  node  to  be  visited  en  route  to  the  final  destination,  dest .  src 
identifies  the  packet’s  original  sending  node,  ssn  is  the  packet’s  session  identifier,  rb  is  the 
amount  of  resource  available  to  the  packet,  rf  is  the  routing  function  to  use  for  forwarding,  and 
the  pair  (val  ,  val  1 )  is  a  chunk  consisting  of  a  function  val  to  apply  and  a  list  of  arguments 
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vail.  A  PLAN  program  is  executed  by  injecting  a  packet  into  the  network  at  the  source  node. 
The  packet  is  given  a  fresh  session  identifier  and  its  chunk  contains  the  program  entry  point  and 
data. 

The  rules  specifying  how  PLAN  packets  execute  in  the  network  are  organized  in  three  groups: 
functional  reduction  rules  that  involve  only  the  process  state,  rules  for  sending  and  receiving 
packets,  and  service  rules.  To  give  a  flavor  of  the  specification  we  present  a  few  representative 
rules. 

Let  rules.  The  functional  rules  are  further  divided  into  control  and  reduction  rules.  Control  rules 
describe  the  factoring  of  an  expression  into  a  reduction  context  and  a  redex,  thus  expressing  the 
flow  of  control  in  a  program.  Reduction  rules  give  the  meaning  of  individual  language 
constructs.  We  illustrate  this  for  the  case  of  let  expressions.  A  let  expression  has  the  form  Let 
[idl  =  exl]  ex,  where  idl  is  an  identifier  list,  exl  is  a  list  of  expressions  whose  values 
are  to  be  bound  to  the  identifiers,  and  ex  is  the  body — to  be  evaluated  using  the  bindings.  The 
control  rule  for  let  specifies  that  the  elements  of  the  expression  list  are  evaluated  in  left-to-right 
order. 

rl  [let-control] 

RedState (cx.  Let  [idl  =  (vail,  nval,  exl)]  ex) 

=> 

RedState (<  ?  :=  Let  [idl  =  (vail,  ?,  exl)]  ex  >  cx,  nval) 

Here  vail  is  a  value  list  and  nval  is  a  nonvalue  expression.  The  let  reduction  rule  is 

rl  [let-reduce] 

RedState (cx.  Let  [idl  =  vail]  ex)  . 

=> 

RedState (cx,  [idl  :=  vail]  ex)  . 

where  [idl  :  =  vail]  ex  is  the  result  of  substituting  values  in  vail  for  corresponding 
identifiers  (variables)  in  idl  in  ex.  Note  that  let  is  the  functional  analog  of  declaration  and 
initialization  of  variables  in  a  language  like  C  or  Java.  Because  updating  is  not  allowed  we  can 
calculate  symbolically  by  substitution. 

Packet  rules.  The  PLAN  resource  model  bounds  the  number  of  packets  that  can  be  sent  in  the 
process  of  executing  a  PLAN  program,  with  packet  forwarding  counted  as  a  send.  The 
expression  OnNeighbor  (val  vail,  Addr  desk,  Int  int)  sends  a  packet  to 
neighbor  desk.  The  packet’s  chunk  is  (val  ,  vail) ,  and  its  resource  bound  is  ink,  which 
must  be  subtracted  from  the  sender’s  available  resources.  This  is  specified  by  the  following 
(conditional)  rule: 
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crl  [packet-send] 

Process (1,  src,  ariv,  rb,  rf. 

RedState(cx,  OnNeighbor  (|  val  |  vail,  Addr  dest,  Tnt  int) ) ) 

=> 

Process (1,  src,  ariv,  (rb  -  int),  rf,  RedState (cx.  Dummy)) 

Packet (dest,  dest,  src,  (int  -  1),  no-rf,  val,  vail) 
if  (rb  >=  int)  and  (int  >  0) 

A  packet  has  arrived  at  its  destination  if  its  next  hop  and  destination  addresses  are  the  same,  and 
it  arrives  at  the  node  whose  deviee  address  list  contains  this  address.  In  this  case  a  proeess 
belonging  to  the  addressed  node  is  ereated.  The  arrival  address  of  the  proeess  is  the  packet’s 
destination  address,  and  the  souree,  session  identifier,  and  resouree  bound  of  the  proeess  are 
given  by  the  corresponding  paeket  parameters.  The  initial  reduction  state  has  empty  context,  “?“, 
and  expression  formed  by  application  of  the  chunk  function  to  its  value  list. 

crl  [packet-receive ] 

Node  (1  ,  devs,  nbrs,  rt) 

Packet (dest,  dest,  src,  ssn,  rb,  rf,  val,  vail) 

=> 

Node  (1  ,  devs,  nbrs,  rt) 

Process (1,  src,  dest,  ssn,  rb,  RedState (?,  (val  vail))) 

if  contains (devs , dest ) 

Service  rules.  Service  operations  allow  a  packet  to  access  and  in  some  cases  modify  the  state  of 
the  node  on  which  it  is  executing.  ThisHost  is  a  nullary  operation  that  returns  a  list  of  the  node’s 
device  addresses. 

rl  Node ( 1 , devs , nbrs , rt ) 

Process (1,  src,  ariv,  ssn,  rb,  RedState (cx,  ThisHost  (  ))) 

=> 

Node  (1,  devs,  nbrs,  rt) 

Process (1,  src,  ariv,  ssn,  rb,  RedState (cx,  cast(devs))) 

cast  (devs)  converts  the  node’s  representation  to  PLAN  data.  The  resident  data  service 
operation  Put  (String  str.  Key  key,  val,  mt  ttl)))  stores  val,labeled  by  str,key,  in  the  data  set 
belonging  to  the  node  with  time-to-live  ttl. 

rl  Data ( 1 , dll ) 

Process (1,  src,  ariv,  ssn,  rb, 

RedState (cx.  Put  (String  str.  Key  key,  val,  Int  ttl))) 

=> 

Data (1, put (dll, str, key, val, ttl) ) 

Process (1,  src,  ariv,  ssn,  rb,  RedState (cx.  Dummy)) 


4.2  Testing  the  Maude  Specification  of  PLAN 

A  formal  specification  is  like  a  mathematical  theory:  spelling  out  the  details  in  a  formal  notation 
does  force  one  to  clarify  concepts  and  to  make  many  implicit  assumptions  explicit,  but  there  is 
no  guarantee  that  the  specification  is  correct  (represents  the  intended  model)  or  usable.  The 
specification  must  be  subjected  to  further  examination  and  tests.  Like  system  requirements. 
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whether  or  not  a  formal  specification  is  correct  is  subjective  and  cannot  be  mechanically 
checked.  However,  like  a  mathematical  theory,  one  can  derive  consequences  (predictions)  and 
compare  these  to  observed  or  desired  properties. 

In  addition  to  checking  the  execution  semantics  of  the  Maude  specification  of  PLAN  against  the 
paper  specification  [24]  we  proved  a  number  of  general  properties  of  PLAN  programs  implied  by 
the  Maude  specification: 

(t)  PLAN  programs  terminate — if  a  packet  is  injected  into  the  network  with  a  fresh 
session  identifier,  then  eventually  all  packets  with  that  session  identifier  are 
delivered,  and  all  pro  cesses  with  that  session  identifier  terminate  execution  with  a 
reduction  state  having  one  of  the  following  forms: 

(ti)  an  empty  context  and  value 

(t2)  an  empty  context  and  a  redex  Print  val  returning  val  to  the  source  node 
(t3)  a  redex  that,  if  executed,  would  send  a  packet  with  more  resource  than  is  available 
(t4)  a  redex  that,  if  executed,  would  be  a  runtime  error 

(ni)  Packets  injected  into  a  network  with  no  pre-existing  (accessible)  data  elements 
execute  independently — that  is,  execution  of  packets  with  different  session 
identifiers  can  be  considered  separately,  since  the  only  mechanism  for  interaction  is 
shared  access  to  data  elements. 

(r)  For  a  PLAN  program  to  visit  each  node  of  a  network  by  repeatedly  sending  packets 
to  all  neighbors  (one  to  each)  it  is  sufficient  to  start  with  rb  >  2w^,  where  d  is  the 
diameter — the  length  of  the  longest  path  between  nodes,  and  w  is  the  width — the 
maximum  number  of  neighbors  of  any  node.  To  have  k  units  left  at  every  terminal 
point,  it  is  sufficient  to  start  with  rb>  (k  +  2)wd. 

In  the  case  of  PLAN,  these  tests  not  only  help  to  validate  the  model,  but  also  improve  the 
usability  from  the  language  designer’s  point  of  view.  For  example,  the  independence  result  can 
be  analyzed  to  arrive  at  criteria  for  additional  Service  Packages  to  assure  desired  noninterference 
among  packets  belonging  to  different  sessions  or  other  groups. 

A  polymorphic  type  system  and  typing  rules  have  been  defined  for  our  generalized  PLAN  along 
with  a  first  prototype  of  a  type  inferencer.  For  PLAN  programs  that  are  typeable,  the  termination 
case  (t4)  does  not  arise.  The  typing  rules  combined  with  strategies  for  use  of  the  rules  to  detect 
type  errors  are  the  basis  for  formalizing  the  notion  of  anytime  type-checking. 

4.3  Testing  and  Analyzing  Particular  PLAN  Programs 

To  test  the  usability  of  the  specification  from  the  programmer’s  point  of  view,  we  selected 
several  PLAN  programs  and  subjected  them  to  a  spectrum  of  formal  analyses.  The  general 
approach  for  these  exercises  was  to 

(1)  represent  the  program  as  a  Maude  term  (a  simple  syntactic  modification,  which  could  be 
automated) 

(2)  define  a  suite  of  test  configurations,  each  determined  by  a  network  configuration  and 
program  input — also  represented  as  Maude  terms 

(3)  run  the  test  configurations  using  the  Maude  interpreter 


17 


(4)  further  analyze  the  possible  eomputations  of  the  test  eonfigurations  using  Maude’s 
seareh  and  model  eheeking  tools 

(5)  prove  properties  of  interest  for  arbitrary  network  eonfigurations  and  inputs  (using 
ordinary  rigorous  mathematieal  reasoning  based  on  the  formal  model) 

Exeeution  and  analysis  ean  be  done  by  exeeuting  and  reasoning  about  the  PLAN  interpreter, 
taking  the  test  eonfigurations  as  input.  However,  this  means  eonsidering  a  lot  of  detail  that  we 
would  rather  not  see.  To  solve  this  problem,  we  developed  a  speeialization  transformation  that, 
given  a  PLAN  program,  produees  a  Maude  module  defining  abstraet  program  states  and  rules,  so 
that  exeeutions  of  the  abstraet  program  are  the  same  as  those  of  the  original  program  if  one  only 
observes  paeket  and  serviee  rules.  The  idea  for  the  transformation  was  based  on  similar 
teehniques  that  have  been  used  for  rewriting  semanties  of  aetor  languages  [29,  42]  eombined 
with  general  methods  for  speeialization  of  funetional  programs.  The  resulting  program  modules 
look  very  mueh  like  the  handeoded  rules  previously  developed  for  analyzing  PLAN  programs 
using  Maude  [15]  and  seem  well  suited  for  use  of  the  speeifieation  as  a  testing  and  simulation 
environment.  Preliminary  experiments  indieate  that  eomputations  in  the  speeialized  modules  run 
about  20  times  faster  than  those  using  the  PLAN  interpreter,  whieh  is  reasonable  for  elimination 
of  interpreted  overhead. 

As  a  eonerete  illustration,  we  will  use  one  of  the  route  finding  programs  published  in  [26].  When 
a  find  paeket  is  injeeted  at  some  node  in  the  network  and  given  a  destination  address,  the 
eomputation  is  initialized  by  determining  the  address  of  the  starting  node,  and  generating  a  new 
key  for  labeling  data.  The  program  has  two  main  funetions — find,  for  the  forward  seareh  for  the 
node  with  the  destination  address,  and  goback,  that  returns  to  the  souree,  assembling  a  route  on 
the  way,  by  following  marks  left  by  the  forward  seareh.  The  assembled  route  list  is  returned  to 
the  souree  node.  Lor  most  of  our  tests  we  used  the  speeialized  version  of  the  find  program,  whieh 
greatly  simplified  the  exeeution  and  analysis.  A  sample  network  eonfiguration,  example-net 
for  testing  this  program  is  shown  in  Ligure  2.  Exeeuting  the  program  starting  at  node  0  with 
destination  e4  returns  the  route  (al ,  c3 ,  e4 )  indieated  in  the  figure  by  the  dashed  line. 

All  the  example  runs  produeed  a  single  path  from  souree  to  destination.  We  eonjeetured  that  in 
general  at  most  one  path  would  be  discovered.  However,  an  attempt  to  prove  this  failed  when  we 
discovered  that  certain  (unlikely)  interleavings  of  execution  of  marking  operations  resulted  in  the 
possibility  of  more  than  one  path  being  discovered.  We  used  the  newly  developed  Maude  model 
checking  capability  to  find  an  actual  example  run  where  this  happened.  The  actual  Maude 
command  was 

red  init-al  1=  [  ~  PrintTwice. 

Here  the  configuration  to  be  checked  is  init-al,  PrintTwice  is  a  property  satisfied  by  a 
configuration  in  which  there  are  two  processes  printing  answers  on  the  packet  source  node,  and 

[  ]  ~PrintTwice 

is  a  temporal  logic  formula  that  is  satisfied  only  if  no  reachable  configuration  satisfies 
PrintTwice.  The  model-checker  returned  a  counterexample  showing  a  possible  computation  in 
which  two  distinct  paths  from  source  to  destination  were  returned  to  the  source. 

Linally,  we  proved  some  correctness  properties  of  the  find  program: 
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(fl) 


If  the  find  program  started  at  node  “1”  with  destination  “d”  prints  “p”  at  the  souree,  then 
“p”  is  a  path  from  “1”  to  “d”. 


Figure  2  A  Plan  Network 


(f2)  If  the  find  program  started  at  node  “I”  with  destination  “d”  is  given  sufficient  resources 
and  there  is  a  route  from  “I”  to  “d”,  then  eventually  there  will  be  at  least  one  process  that 
prints  a  path  at  the  source  node  “1”. 

The  proof  is  simplified  by  making  use  of  the  general  properties  of  PLAN  programs  stated  above. 
Note  that  the  resources  needed  in  (12)  can  be  computed  using  the  general  result  (r). 

4.4  PLAN  in  Maude  Conclusions 

We  emphasize  that  testing  a  specification  as  we  did  is  an  extremely  important  part  of  the  process 
of  developing  a  formal  model.  In  fact  the  specification  presented  here  is  the  second  major 
version;  the  first  version  we  developed,  which  served  to  clarify  many  issues  and  fill  in  many 
gaps,  was  too  complex  to  be  useful. 

Our  task  was  made  much  easier  thanks  to  the  existence  of  the  paper  specification  and  other 
documentation.  Formalization  required  filling  in  some  gaps  and  we  made  some  alternate  choices 
in  modeling  the  network  to  achieve  greater  modularity  and  concurrency. 

Regarding  making  the  specification  usable  by  a  diverse  community,  the  current  version  is  a  good 
start;  what  is  needed  now  is  to  develop  tools  that  help  others  use  it.  This  includes  techniques  and 
tools  for  checking  implementation  conformance,  support  for  graphical  animation  of  packets 
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executing  in  a  network,  automating  the  specialization  process,  and  developing  even  stronger 
abstractions  to  support  application  of  model  checking  and  verification  tools. 

Future  developments  of  the  specification  include  modeling  dynamic  network  topology,  real-time 
aspects,  and  security  properties. 

5  Conclusions  and  Future  Developments 

Modeling  and  formally  analyzing  active  network  systems  and  protocols  is  quite  challenging,  due 
to  their  highly  dynamic  nature  and  the  need  for  new  network  models  that  renders  approaches 
based  on  standard  models  inadequate.  We  have  proposed  a  highly  flexible  semantic  framework 
for  executable  formal  specification  of  active  network  systems  and  languages,  namely  rewriting 
logic.  We  have  also  shown  how,  in  conjunction  with  its  Maude  implementation  and  the  Maude 
formal  tools,  active  network  systems,  languages,  and  protocols  can  indeed  be  formally  specified 
and  analyzed  using  a  flexible  range  of  formal  methods.  In  this  way  one  can  gain  (1)  a  precise 
documentation  of  their  design,  (2)  the  early  discovery  of  many  bugs,  and  (3)  higher  assurance 
about  their  correctness.  We  have  illustrated  these  methods  and  their  practical  usefulness  through 
two  active  networks  case  studies:  the  AER/NCA  protocol  suite  and  the  PLAN  executable 
semantics. 

Our  goal  has  been  to  insert  formal  methods  from  the  early  stages  of  next-generation  network 
system  design.  Our  experience  in  all  the  active  networks  case  studies  that  we  have  conducted  has 
been  very  positive,  indicating  that  this  can  indeed  be  done  with  relatively  low  cost  and  with 
substantial  benefits.  Cost  should  be  measured  not  only  in  terms  of  amount  of  effort  required  by 
the  methods,  but  also  in  terms  of  the  difficulties  for  network  engineers  in  using  a  formal  notation. 
On  both  counts  our  experience  validates  a  low  cost.  The  rewrite  rule  formalism  is  very  close  to 
the  transition  diagram  notation  that  network  engineers  use  routinely — in  fact,  much  closer  than 
informal  specifications  like  use  cases.  Also,  the  fact  that  great  benefits  can  be  drawn  even  from 
“lightweight”  methods,  such  as  symbolic  simulation  of  the  design  using  the  Maude  specification, 
greatly  lowers  the  usual  barriers  to  the  adoption  of  these  methods  within  the  design  process. 

Our  experience  has  been  very  positive,  but  more  research  is  needed  to  make  these  ideas, 
methods,  and  tools  accessible  to  network  engineers.  We  consider  the  following  future  research 
directions  to  be  key  to  further  advancing  this  goal: 

•  Integration  with  network  simulation  and  validation  tools.  Our  methods  and  tools  should 
be  integrated  with  other  tools  supporting  network  design,  including  simulators;  in  this 
way,  interoperation  between  different  design  notations  and  their  supporting  tools  will 
allow  sophisticated  analyses  of  designs  at  different  levels  of  abstraction  in  a  way  not 
currently  possible. 

•  Extensions  of  our  methods  to  real-time  verification.  Our  methods  can  be  applied  not  only 
to  designs,  but  also  to  the  systems  built  from  those  designs.  In  this  way,  specification- 
based  testing  and  monitoring  of  the  implemented  systems  also  becomes  possible.  The 
positive  experience  about  this  kind  of  real-time  verification  using  Maude  in  [17]  suggests 
that  this  as  a  promising  and  very  practical  direction. 

•  Development  of  domain-specific  tools.  Our  experience  with  PLAN,  which  at  present 
lacks  a  simulator,  suggests  that,  based  on  the  Maude  executable  specification  of  a 
language  of  a  system,  very  useful  special-purpose  tools  for  that  system — such  as 
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simulators,  debuggers,  verifiers,  and  animation  tools — can  be  developed  with  relatively 
low  effort. 

•  Advancing  the  Maude  formal  methods  and  tool  infrastructure.  To  scale  up  to  large 
applications,  high-performance  tools  and  compositional  methods  become  essential. 
Present  and  future  advances  on  Maude  and  its  supporting  tools  are  a  key  infrastructure 
that  needs  to  be  further  advanced.  For  example,  the  high  performance  of  the  Maude 
interpreter  can  be  in  creased  by  a  compiler,  and  the  recent  C++  implementation  of  the 
Maude  LTL  model  checker  will  allow  dealing  with  much  bigger  examples  than  possible 
with  previous  prototype  tools.  Hand  in  hand  with  more  efficient  tools,  compositional 
proof  methods  also  need  to  be  developed. 

•  Code  generation  and  Maude-based  network  languages.  The  gap  between  specifications 
and  implementations  can  be  drastically  reduced  by  semantics-preserving  methods  that 
generate  code  from  executable  Maude  specifications.  This  could  be  done  for  a  variety  of 
languages,  including  conventional  languages  such  as  Java  (see  the  promising  approach 
presented  in  [28]  and  for  distributed  and  mobile  languages  directly  based  on  Maude  such 
as  Mobile  Maude  [13]. 
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